Some client devices operate in a passive mode and do not accept commands from or provide status information to the servers with which they have established a connection, such as a TCP (Transmission Control Protocol) connection. The communication between the server and the client device is one way only in the direction from the client device to the server. The client device simply transmits relevant data to the server for processing. No information is provided by the client device to the server regarding the status of the client device or the connection between the server and the client device. Thus, the server does not know when the client device or the connection between the server and the client device becomes non-operational. Most TCP implementations allow in-bound connection requests to be stored into a socket connection queue of the server. A new connection request stored in the socket connection queue is not accepted by the server until the currently open connection is explicitly closed. Thus, data that is being transmitted by the client through a new connection that has not been accepted by the server will be lost forever.
Existing systems may include a TCP socket “keepalive” option. When the “keepalive” option is active for a TCP socket and no data has been exchanged across the socket for a period of time, typically two hours, a “keepalive” probe is sent by the server to the client device. The client device may respond to the probe in one of three ways. The client device may respond with an ACK (acknowledged) signal indicating that everything is fine. In such a case, another “keepalive” probe is sent following another two hours of inactivity. Alternatively, the client device may respond with a RST (reset) signal indicating that the client device has crashed and rebooted. In such a case, the socket connection is closed. The third option is that the client device does not respond to the “keepalive” probe. In such a case, it is assumed that the client device has crashed and the socket connection is closed. The period of time after which the “keepalive” probe is then sent to the client device is typically long and is not configurable by a user. As such, a significant amount of data may be lost between two successive “keepalive” probes.